Okay, I'll port the implementation over to Gleam. Is it fine for the FFI code to call (compiled) gleam code again?

P.S.: Does gleam have syntax for getting the ASCII value of a character, like $a becomes 97 in erlang?

Okay, I'll port the implementation over to Gleam. Is it fine for the FFI code to call (compiled) gleam code again?

Ideally Gleam code should retain control, but it can be otherwise if there's a good performance reason.

P.S.: Does gleam have syntax for getting the ASCII value of a character, like $a becomes 97 in erlang?

It does not, no.

It does not, no.

Ah that's unfortunate.

This this is to be accepted the checking code will need to be moved into Gleam rather than replicating the logic in two external implementations.

How do I structure the code? For example, http.method_from_dynamic calls a native function called decode_method, which decodes a method from a string in JS, and a charlist/atom/binary in erlang. This function has to call is_valid_tchar, which is the checking code you're talking about. If I have to move it to gleam, I assume I'll have to make it public, which is unnecessary since it will not be used by library consumers. Instead, I should put it in an internal folder.

There's another way I can do it -- I can make the decode_method function return a string representation of the value passed, and that can then be checked in gleam.

Please let me know what approach you'd prefer.

Sorry for the delay, I've been dealing with family matters.

Let's remove the method_from_dynamic function entirely. It doesn't have a valid use case.

Sounds good!

I've removed the erlang and js ffi modules entirely because they are only used for method_from_dynamic. Please take a look!

Ah! The tests are failing!

The cached compiled beam file made me miss it lol

oops, sorry about that. Would be good if the build tool could handle that nicely

Okay, now they should pass!